Subject: RTP Header Compression for Slow Speed Links

From: [email-masked]
Date: Fri, 3 May 96 15:53:44 EDT

I am posting the following preliminary (and incomplete) Internet
Draft, so that we might get some comments and discussion going on
this list.  Scott and I submitted this just before the last IETF
in Los Angeles.  We plan to resubmit this with the details of the
compression technique we have in mind to the avt working group
mailing list, prior to the next IETF in June in Montreal.

We are also in contact with the pppext working group, which will also
need to be involved in our approach to this problem.  Our intention
is to permit RTP to be used efficiently over dial-up modem lines
as the industry standard for encapsulating realtime voice over the
Internet, including in Internet Telephony applications.

Please feel free to comment on this list, as it will assist us in
bringing forward a proposal which developers of Internet Telephony
software will want to support.  We will post the version with the
technical details of our proposal as soon as possible.  If you have
suggestions regarding which technical alternatives you would support,
now is the time to say so.

We are looking at both VJ Compression and CCP as alternatives.  We expect
that the compression employed will be limited to the low speed link, in
order to facilitate multicast.  (By low speed, this could mean anything
from 14.4kbps up to 128kbps.)  We expect that compression will not be
end-to-end across the Internet.  This saves each end system from being
required to keep compression state associated with all other end systems
in the same multicast group, while retaining the compression on the link
where it is most valuable: the low speed dial up link.

 *************************************************************************

 Internet Draft (Preliminary)                           Scott Petrack
                                                                  IBM
                                                        Ed Ellesson
                                                                  IBM

                                                        February 1996

                 Framework for C/RTP: Compressed RTP Using
                 Adaptive Differential Header Compression

         Abstract:

         RTP (Realtime Transport Protocol) has been adopted as a
         Proposed Standard and is being widely implemented for
         the synchronized transmission of time-stamped data over
         IP networks, and has been shown to be effective at LAN
         speeds, T1 speeds, and Basic Rate ISDN speeds (128 kbps).
         However, a large number of users access the Internet at
         speeds of 14.4 and 28.8 kbps.  In order for such users
         to realize the maximum benefit of realtime audio and video
         applications, it is reasonable to apply whatever means
         possible to reduce header overhead.  A framework for
         header compression of RTP and for associated control
         protocols is herein proposed for use in these low
         bandwidth realtime scenarios.

 Introduction:

 RTP (Realtime Transport Protocol) has been adopted as a Proposed
 Standard, and is being widely implemented, for the synchronized
 transmission of time-stamped data over IP networks, and has been shown to
 be effective at LAN speeds, T1 speeds, and Basic Rate ISDN speeds (128
 kbps).  However, a large number of users access the Internet at speeds of
 14.4 kbps and 28.8 kbps.  In order for such users to realize the maximum
 benefit of realtime applications, it is reasonable to apply whatever
 means possible to reduce header overhead.  By reducing header overhead,
 the relative amount of bandwidth available for transmission of realtime
 audio or video packets can be dramatically increased, while maintaining
 acceptable packetization delay.  At these low speeds, a few kbps in
 additional realtime packet throughput can make a dramatic difference in
 user perception of quality in the received audio or video.

 This draft introduces the concepts which we have utilized to reduce
 header overhead in realtime applications.  In order to negotiate or
 pre-arrange header compression options, a session control protocol is
 assumed.  The Session Description Protocol (SDP), defined by the mmusic
 working group, could easily be modified to pre-arrange such compression
 options for loosely controlled conference sessions.  For tightly
 controlled sessions, the Simple Conference Invitation Protocol (SCIP)
 also being defined by the mmusic working group, could be used to
 negotiate or re-negotiate such options.  Alternatively, a modified H.245
 protocol could also be used to negotiate header compression options as
 part of the "capabilities exchange".  The specific modifications to these
 protocols to control header compression options are beyond the scope of
 this draft.

 RTP's overhead is approximately 12 bytes per packet, at minimum.  The
 impact of this RTP overhead, when used over low speed access lines, is
 aggravated by the fact that in typical real-time audio applications, the
 packet size is particularly small.  A telephony application using an
 advanced codec might transmit 24 bytes every 30msecs.  Each packet is a
 separate UDP write, which adds an additional 8 bytes.  Thus the total
 overhead for both RTP and UDP is approximately 20 bytes for each 24 byte
 packet.  Over a 14.4 kbps connection, one has no choice but to group
 packets together to reduce the bandwidth requirement, which increases
 delay to an unacceptable degree for realtime interactive voice
 conversations.  Even over a 28.8 kbps link, the overhead of RTP/UDP cuts
 into the bandwidth available to audio and video applications.  This
 translates directly into larger delays in the available service, because
 the payloads must be grouped into larger packets to amortize the RTP/UDP
 overhead.

 This draft documents two ideas that we have used to reduce the overhead
 of RTP from 12 bytes to 2 bytes.  This reduction allows us to to
 effectively eliminate the delay caused by RTP overhead on a low speed
 link.  Although applying Van Jacobsen compression to the headers is
 helpful, it is limited by the rapidly varying sequence number and
 timestamp information.  The general compression scheme described here can
 be summarized thus: the timestamp and sequence number fields taken
 together include redundant time signal information.  They can be
 compressed by standard adaptive differential methods.

 The extra compression is based on two ideas:

     1. Use the time-related nature of the sequence and time stamp fields.
        In many cases, timestamps can be replaced by "timeclick numbers"
        which are one byte long, and these can be combined with the
        RTP sequence numbers. In general the timestamps and sequence
        numbers themselves form a simple time signal, and can be
        compressed without loss by standard adaptive differential
        methods.

     2. Negotiate compression options before starting the RTP session.
        In many cases, certain RTP header fields do not change at all
        during the life of an RTP session.

 The two ideas presented here can be used independently.  For example, one
 could send all the header fields in each packet, but still use the
 special time-related nature of some of the fields to compress them.  The
 application that first interested us is transmitting audio and
 audio/video over a PPP link.  In this case the two ideas together give a
 much more efficient use of bandwidth.

 Time-related compression:

 The basic idea here is that one cannot compress time-related data by the
 usual VJ compression, because time related data is constantly changing.
 But the changes in the time related data are often simple to model, and
 an "adaptive differential" scheme can give good lossless compression.
 For example, suppose there are no packet losses and the time stamp of
 each packet increases by exactly one.  In this case, each timestamp is
 different, so VJ compression will not compress, but in fact one can
 dispense entirely with the timestamp field after the first.

 In general, there are two separate fields which relate to time:
 the RTP sequence number, and the timestamp.

 In our internet telephone example, we have an application which sends one
 UDP packet every 20msecs, except that during silence it sends nothing.
 We always send the packets in order.  Instead of the timestamp and the
 RTP sequence number, we send a single "timeclick number" with each
 packet.  Each number represents 20 msecs, and from the timeclick number
 we know exactly when it was sent (modulo 256*20msecs=5.12secs).  Thus we
 have a precise model for timestamps(i.e. timestamps always increase by
 20msecs), and this allows us to transmit the information in a single
 byte.

 Session control and compression:

 The second idea is an extension of well known VJ compression.  We have
 found that in multimedia applications over low-speed links, every bit can
 be very precious.  VJ compression is an in-band technique, and uses a few
 bits to signal a header which doesn't change.  One can save several a few
 hundred bits per second by signalling the static parts of the headers out
 of band.  We now discuss this technique.

 RTP is designed to run over connectionless, unreliable protocols, but it
 has inherent in it the idea of an RTP session.  We have found that it is
 very natural to set up, control, and tear down an RTP session using a
 separate session control protocol, which, in our implementation, uses a
 reliable form of transmission.  The RTP bytestream itself still runs over
 the unreliable protocol - only the non-real-time control is done via a
 the session control protocol.  One of the important benefits of doing
 this is that we can compress the unreliable RTP bitstream even further.

 Example:  Think of a simple audio/video transmission application
 (multicast or unicast).  Before streaming begins, some negotiation or
 advertisement takes place (coder type, block size, bandwidth, etc.).  In
 this way, each side has a common understanding of the coming RTP
 bytestream.  (In our current implementation, the receiver sends a "ready
 to receive" to the sender, and then the sender can start streaming - an
 RTP session has begun.)  The RTP bytestream itself is sent over UDP/IP to
 facilitate real time transmission.  To change a parameter in a session,
 the RTP session stops streaming, and only then some new negotiation takes
 place or the session is torn down and a new one established.

 One can use this model to implement every commonly used "phone service",
 including multiparty conferencing.  The simplifying assumption is that an
 RTP parameter can be negotiated only while the RTP stream is not
 streaming.  This negotiation can take place in a comparatively leisurely
 non-real-time manner.

 From an end user perspective, pausing the realtime flow to renegotiate
 the control state is not unfamiliar.  Note that this model is very
 similar to that provided by an ordinary analog phone call.  You pick up
 the receiver and do some reliable signalling to set up a connection.
 Once connected, the real-time stream is highly unreliable (noise, echo,
 etc.).  In order to change the control state of the connection, the
 exchange of real-time data must be suspended or stopped (call must be put
 "on hold" or disconnected).  In analog phone systems, the "on hold"
 indication is often signalled via a timed "hook flash", or temporary
 disconnect.  In this paused state the real-time bitstream can be
 renegotiated (e.g., you can dial someone else, etc.).  We do not propose
 this model for all RTP realtime flows, but only those that are associated
 with applications which can dramatically benefit from header compression
 signaling via a separate session control mechanism.

 Here is the precise definition of our session mechanism:

 1.  The originator contacts the receiver via some negotiation or
 advertisement protocol and informs or negotiates in non-real-time the
 bytestream characteristics.  (In our implementation, this phase ends with
 the sender sending a messaging expressing readiness to receive.)

 2. At this point the sender can start sending to the receiver using RTP.

 3.  At any point in the stream, the sender can stop sending and then send
 a "pause announcement".  This pause announcement is sent via the session
 control protocol.  (In our current implementation, the receiver
 acknowledges this pause announcement.)  Similarly, the receiver can send
 a "pause request" and then wait for the sender to stop sending.  (In our
 current implementation, the sender complies with such a request by
 stopping to send, and also acknowledges the request by sending a "pause
 announcement" in the control protocol.)

 4.  Once the realtime stream is paused, and the correct pause message has
 been received on each side, then the control connection can be used to
 renegotiate the bitstream (return to item 1, above), or to end the
 session.

 There are two important points about using the above scheme:

 - The RTP bytestream itself is sent by UDP/IP, a stateless protocol.
 All the state information is negotiated in the session control protocol.
 This is possible because there is a very simple synchronization between
 the two channels, done in non-real time.  The statelessness of the RTP
 stream makes it very simple to fulfill the realtime requirements.

 - The fact that all negotiation is done BEFORE the RTP stream begins,
 allows the two sides to agree not to send RTP header information that is
 going to remain static throughout the session.  Without this prior
 negotiation, some bits would have to be used to flag these RTP header
 fields.  By simply not transmitting these bits at all, one can squeeze
 several hundred extra bits per second out of a low speed serial link.
 This is often very precious when one is transmitting realtime audio or
 video over a 14.4 kbps link.

 To summarize, although RTP allows the possibility to perform control of
 the bitstream on the fly, in practice one can often agree in advance not
 to do this, with no real loss in the useability of the available service,
 depending on the application.

 Multicast Considerations:

 The above discussion spoke about point-to-point unicast only for
 simplicity.  It is easy to generalize to multicast environments, if a
 advertisement or agreement protocol is used to synchronize the state of
 the multiple endpoints.  The essential ideas (using a session protocol to
 negotiate the stateless RTP stream, negotiating to omit uneccessary
 fields, and performing an adaptive differential compression on the time
 stamps and sequence numbers) apply equally in the multicast case.

 Summary:

 We have found that much useful real-time conferencing can be done over
 14.4 and 28.8 kbps links.  But the difference between the 8+12 byte
 overhead of RTP/UDP and 8+2 byte overhead of C/RTP can be the difference
 between acceptable audio/video quality and intolerable audio/video
 quality.  We definitely think that it is worth supporting 14.4kbps links
 for real-time multimedia.

 References:

 1. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A
    Transport Protocol for Real-Time Applications", RFC1889,

 2. H. Schulzrinne, "RTP Profile for Audio and Video Conferences with
    Minimal Control", RFC 1890,

 3. M. Handley, V. Jacobson, "SDP: Session Description Protocol",
    Internet-Draft, Nov. 22, 1995.

 4. H. Schulzrinne, "Simple Conference Invitation Protocol", Internet-
    Draft, February 22, 1996.

 Author's Addresses:

 Scott Petrack
 IBM Science and Technology Center
 Haifa, Israel
 Email: [email-masked]

 Ed Ellesson
 IBM Networking Architecture
 Research Triangle Park, NC, USA
 Email: [email-masked]
*******************************************************************************

Regards, Ed

[email-masked]
legacy voice: 919-254-4115

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 May 1996 22:35:43 +0200

A current version of the draft document about the ISSLOW architecture
on providing integrated services over low-bitrate links is in
http://www-rn.informatik.uni-bremen.de/research/isslow.html, .txt, .ps
(the Postscript version probably is the most readable one).

This draft is part of the work proposed for the new Integrated
Services over Specific Link Layers (ISSLL) working group of the IETF
initiated at the March IETF meeting.  I have volunteered to act as a
coordinator for integrated services over low-bitrate links within
ISSLL.

I would like to generate a first internet draft out of this document
very soon -- if any of you have input, in particular on the strawman
proposals on real-time encapsulation and RTP compression in the
Annexes, I would be grateful to receive that.

Gruesse, Carsten

---

From: Bob Lisbonne <[email-masked]>
Date: Fri, 03 May 1996 13:39:21 -0700

Ed,
If you're not already, please be sure to work with the following folks on this list as regards C/RTP:
- Mike Po, in charge of all LiveMedia engineering
- Ed Skonecki, Livemedia product marketing
- Jack Toto, LiveMedia partners and evangelism
thanks very much,
--Bob

---

From: Bob Lisbonne <[email-masked]>
Date: Sun, 05 May 1996 23:36:35 -0700

Carsten,
Please work with Mike Po ([email-masked]) and Ed Skonecki ([email-masked]) on your RTP 
proposals.
thanks,
--Bob